A point-of-sale (POS) application is typically used in retail stores to replace traditional cash registers. The POS application automates transaction processing from start to finish for various types of transactions such as sales, returns, work orders, layaways, and quotes. In addition, the POS application streamlines inventory management and reporting, makes it easy to track customer information, and maintains detailed customer history.
Payment data collecting and payment processing are core parts of retail sales transactions performed by a POS application. Within a POS application, the store owner can create a set of pre-defined payment methods and associate a set of supported hardware. Each payment method is pre-defined by payment format, an associated payment processor, and properties required by that payment processor. The payment format identifies a set of options applicable to a specific type of payment, such as payments toward customer accounts, cash payments, credit and debit card payments, check payments, vouchers payments, and others. For example, for a debit card payment format, the payment processor typically utilizes properties such as debit card number, expiration date, cash back limit, cash back fee, and a PIN. This is in contrast for a credit card payment format, where the payment processor usually utilizes properties such as, credit card number, expiration date, and credit card security code (e.g., CVV—card verification value), etc.
Each supported piece of payment hardware gathers partial or all required properties for certain payment methods. For example, a PIN pad is designed to gather an encrypted PIN data block from the customer with using a keypad. A magnetic stripe reader (MSR) obtains credit card account and expiration date from the magnetic stripe attached to a plastic card when the customer swipes the card through the device. An intelligent combination (“combo”) device, which has its own onboard workflow, can function as both an MSR and a PIN pad at the same time.
At specified times when no hardware is utilized, a retail application can prompt the cashier to manually input payment data in lieu of getting the payment data automatically from hardware. Once all required payment data is gathered, the retail application communicates the payment data and amount desired to the payment processor, and then receives payment authorization.
Payment format and payment processor requirements vary greatly from jurisdiction to jurisdiction and can change over time. The POS product needs to have the necessary built-in support for collecting payment data and communicating the payment data to the payment processors in each jurisdiction where the product will be used. However, as the product expands and serves retail businesses in new markets, there is currently no way for the POS product to support new payment requirements in the new markets without requiring a new release of the POS application.